Long story short, we need this to customize the effective viscosity calculation but keeping the rest of the constitutive law ¿right?.

This is exactly what I want. I am open to suggestions. This was the only way i found which is easier to look at, extend and manage FluidConstitutiveLaws. Constitutive laws are so complicated, and has lots of elements containers assigned to them, and I don't know how to manage them if we make duplicates everywhere :/

I want to confirm that this is the problematic and to better discuss it before merging.

I agree. Even ConstitutiveLaw::Parameters are also kind of complicated, and I don't totally get the signature of the ConstitutiveLaw::CalculateValue also. I would like to hear all the opinions :)

you can get documentation of the CL in the wiki. In my opinion using the CL is a must...

@RiccardoRossi thanks :).... A small question, I'm just curious, why does ConstitutiveLaw::CalculateValue take output value as a reference and as well as have the return type of the same? (In the followgin takes double& and returns a double as well.

Then its gonna be same as the previous approach, (The template paramter was made the base class) I thought that is what you wanted to avoid, have dependencies which makes developement harder.

Previously what I had was something like this

template<class TBaseClassType>
class RansConstitutiveLaw : public TBaseClassType
{
protected:
      // overriding the GetEffectiveViscosityMethod
};

template class RansConstitutiveLaw<Newtonian2DLaw>;

And proposed deriving also will have the same (apart from the template argument)

class RansConstitutive2DLaw : public Newtonian2DLaw
{
protected:
      // overriding the GetEffectiveViscosityMethod
};

I dont see much difference in two methods

1. 1st method will only require RansConstitutiveLaw class (only two files) - less room for coding errors
2. 2nd method will require two classes 'RansConstitutive2DLawandRansConstitutive3DLaw` (needs 4 files) - more room for coding errors

What do you think? (Thats why recreated the whole laws from scratch so it can be decoupled for furture developements and expansions - current state of this PR)

The point is that I can't foresee so much room for further developments and expansions for a Newtonian law. The idea of method 2 is precisely that, avoid the template argument. Note that as it is right now it requires 4 files but only one method override, which can be eventually implemented in an external utility. Also note that the constitutive laws in the FluidDynamicsApplication could be eventually templated with the dimension. This is not done yet because of legacy reasons (some of the non-Newtonian constitutive models have no 2D version yet). By doing so we will end up with a two files implementation as option one.

@rubenzorrilla Done. Could you have a look?

Hi @rubenzorrilla , I addressed all of your comments. Could you have a look?

thanks @rubenzorrilla :)